Adaptive content management

ABSTRACT

Methods and systems for enabling a user to define a webpage and webpage layout without knowing a programming language are disclosed. A library of modules is provided usable to configure a layout and look of a webpage. The user may add modules from the library to a webpage layout design area. The user may configure a given module so as to control the look and feel of the content accessed and displayed by the module. Different instantiations of the same module may be used to access content from different sources, including sources using different file and data formats. Content from the different sources may be accessed and stored in a schema-less database.

INCORPORATION BY REFERENCE TO ANY PRIORITY APPLICATIONS

Any and all applications for which a foreign or domestic priority claimis identified in the Application Data Sheet as filed with the presentapplication, are hereby incorporated by reference in their entiretyunder 37 CFR 1.57.

BACKGROUND OF THE INVENTION

Field of the Invention

The field relates to content management, such as content management forelectronic document content.

Description of the Related Art

A plugin is also known by other names, such as extension, widget, ormodule. Plugins are typically built to work with external data and maybe configured to ingest content or display content on a webpage. Pluginsmay be used to extend the functionality of a content management systemto enable functionality to be added to a user's website.

SUMMARY

The following presents a simplified summary of one or more aspects inorder to provide a basic understanding of such aspects. This summary isnot an extensive overview of all contemplated aspects, and is intendedto neither identify key or critical elements of all aspects nordelineate the scope of any or all aspects. Its sole purpose is topresent some concepts of one or more aspects in a simplified form as aprelude to the more detailed description that is presented later. It isunderstood that while various aspects are described, certain embodimentsmay include any combination of the described aspects, or subsetsthereof.

An aspect of the disclosure includes methods and systems for enabling auser to define a webpage and webpage layout without knowing aprogramming language are disclosed. A library of modules may be providedthat is usable to configure a layout and look of a webpage. The user mayadd modules from the library to a webpage layout design area (e.g.,using a drag-and-drop or other technique). The user may configure agiven module so as to control the look and feel of the content accessedand displayed by the module. Different instantiations of the same modulemay optionally be used to access content from different sources,including sources using different file and data formats. Content fromthe different sources may be accessed and stored in a schema-lessdatabase.

An aspect of the disclosure includes a computer-implemented method ofconfiguring a web page layout, the method comprising: providing a useraccess to a library of modules usable to configure a layout of awebpage, wherein a given module from the library of modules is userconfigurable, without the user programming in a programming language, tocontrol how content is to be displayed on a webpage; enabling the userto drag and drop one or more modules from the library of modules onto awebpage layout design area to define a webpage layout; providing, for agiven module selected by the user, a module configuration userinterface, wherein the module configuration user interface enables theuser to specify what content is to be displayed on the webpage beingdesigned and how the content is to be displayed without the user havingto program using a programming language, wherein the module userinterface comprises interfaces configured to receive at least: accessinformation for content from a source, the access information includingat least a content locator; content attributes comprising at least oneattribute affecting how content from the source is displayed; receivinga user specified layout for a first webpage specified by the user viathe webpage layout design area, wherein the user specified layoutcomprises a layout of a plurality of modules, including: a firstinstantiation of a first module configured by the user to specify accessinformation and at least one attribute for a first content source thatprovides content using a first content format; a second instantiation ofthe first module configured by the user to specify access informationand at least one attribute for a second content source that providescontent using a second content format, the second content formatdifferent than the first content format; accessing content from thefirst content source based at least in part on the user configuration ofthe first instantiation of the first module, including at least aportion of the user specified access information for the first source,wherein the content from the first content source utilizes the firstcontent format; storing content from the first content source in aschema-less data store; accessing content from the second content sourcebased at least in part on the user configuration of the secondinstantiation of the first module, including at least a portion of theuser specified access information for the second source, wherein thecontent from the second content source utilizes the second contentformat; storing content from the second content source in theschema-less data store; enabling the webpage to be rendered, includingthe content from the first content source and the content from thesecond content source.

An aspect of the disclosure includes a computer-implemented method ofconfiguring a web page layout, the method comprising: providing a useraccess to a library of modules usable to configure a layout of awebpage, wherein a given module from the library of modules is userconfigurable, without the user programming in a programming language, tocontrol how content is to be displayed on a webpage; enabling the userto instantiate one or more modules from the library of modules onto awebpage layout design area to define a webpage layout; providing, for agiven module selected by the user, a module configuration userinterface, wherein the module user interface comprises interfacesconfigured to receive at least: access information for content from asource, the access information including at least a content locator;receiving a user specified layout for a first webpage specified by theuser via the webpage layout design area, wherein the user specifiedlayout comprises a layout of a plurality of modules, including: a firstinstantiation of a first module configured by the user to specify accessinformation and at least one attribute for a first content source thatprovides content using a first content format; a second instantiation ofthe first module configured by the user to specify access informationand at least one attribute for a second content source that providescontent using a second content format, the second content formatdifferent than the first content format; accessing content from thefirst content source based at least in part on the user configuration ofthe first instantiation of the first module, including at least aportion of the user specified access information for the first source,wherein the content from the first content source utilizes the firstcontent format; optionally storing content from the first content sourcein a schema-less data store; accessing content from the second contentsource based at least in part on the user configuration of the secondinstantiation of the first module, including at least a portion of theuser specified access information for the second source, wherein thecontent from the second content source utilizes the second contentformat; optionally storing content from the second content source in theschema-less data store; enabling the webpage to be rendered, includingthe content from the first content source and the content from thesecond content source.

An aspect of the disclosure includes a system, comprising: a networkinterface configured to communicate over a network; a computing systemcomprising one or more computing devices; a computer storage systemcomprising a non-transitory storage device, said computer storage systemhaving stored thereon executable program instructions that direct thecomputer system to at least: provide, over the network, a user access toa library of modules usable to configure a layout of a webpage, whereina given module from the library of modules is user configurable, withoutthe user programming in a programming language, to control how contentis to be displayed on a webpage; enable the user to instantiate one ormore modules from the library of modules onto a webpage layout designarea to define a webpage layout; provide, for a given module selected bythe user, a module configuration user interface, wherein the moduleconfiguration user interface enables the user to specify what content isto be displayed on the webpage being designed and how the content is tobe displayed without the user having to program using a programminglanguage, wherein the module user interface comprises interfacesconfigured to receive at least: access information for content from asource, the access information including at least a content locator;content attributes comprising at least one attribute affecting howcontent from the source is displayed; receive, over the network, a userspecified layout for a first webpage specified by the user via thewebpage layout design area, wherein the user specified layout comprisesa layout of a plurality of modules, including: a first instantiation ofa first module configured by the user to specify access information andat least one attribute for a first content source that provides contentusing a first content format; a second instantiation of the first moduleconfigured by the user to specify access information and at least oneattribute for a second content source that provides content using asecond content format, the second content format different than thefirst content format; access content from the first content source basedat least in part on the user configuration of the first instantiation ofthe first module, including at least a portion of the user specifiedaccess information for the first source, wherein the content from thefirst content source utilizes the first content format; store contentfrom the first content source in a schema-less data store; accesscontent from the second content source based at least in part on theuser configuration of the second instantiation of the first module,including at least a portion of the user specified access informationfor the second source, wherein the content from the second contentsource utilizes the second content format; store content from the secondcontent source in the schema-less data store; enable the webpage to berendered, including the content from the first content source and thecontent from the second content source.

An aspect of the disclosure includes a computer storage systemcomprising a non-transitory storage device, said computer storage systemhaving stored thereon executable program instructions that direct acomputer system to at least: provide a user access to a library ofmodules usable to configure a layout of a webpage, wherein a givenmodule from the library of modules is user configurable, without theuser programming in a programming language, to control how content is tobe displayed on a webpage; enable the user to instantiate one or moremodules from the library of modules onto a webpage layout design area todefine a webpage layout; provide, for a given module selected by theuser, a module configuration user interface, wherein the moduleconfiguration user interface enables the user to specify what content isto be displayed on the webpage being designed and how the content is tobe displayed without the user having to program using a programminglanguage, wherein the module user interface comprises interfacesconfigured to receive at least: access information for content from asource, the access information including at least a content locator;content attributes comprising at least one attribute affecting howcontent from the source is displayed; receive a user specified layoutfor a first webpage specified by the user via the webpage layout designarea, wherein the user specified layout comprises a layout of aplurality of modules, including: a first instantiation of a first moduleconfigured by the user to specify access information and at least oneattribute for a first content source that provides content using a firstcontent format; a second instantiation of the first module configured bythe user to specify access information and at least one attribute for asecond content source that provides content using a second contentformat, the second content format different than the first contentformat; access content from the first content source based at least inpart on the user configuration of the first instantiation of the firstmodule, including at least a portion of the user specified accessinformation for the first source, wherein the content from the firstcontent source utilizes the first content format; store content from thefirst content source in a schema-less data store; access content fromthe second content source based at least in part on the userconfiguration of the second instantiation of the first module, includingat least a portion of the user specified access information for thesecond source, wherein the content from the second content sourceutilizes the second content format; store content from the secondcontent source in the schema-less data store; enable the webpage to berendered, including the content from the first content source and thecontent from the second content source.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments will now be described with reference to the drawingssummarized below. These drawings and the associated description areprovided to illustrate example embodiments, and not to limit the scopeof the invention.

FIG. 1 is an overview of an example overall process for handlingcontent.

FIG. 2 illustrates an example process for importing content.

FIG. 3 illustrates an example of how imported content is configured fordisplay.

FIG. 4 illustrates an example of how attributes can be selected whenconfiguring content for display.

FIG. 5 shows an example of how a page layout can be configured.

FIG. 6 illustrates an example process for rendering pages.

FIG. 7A illustrates an example relationship between content sets, items,and attributes.

FIG. 7B illustrates the optional use of a unique ID to reference arespective item.

FIG. 8A illustrates example information that enables a CMS to import andmap a data feed.

FIG. 8B illustrates example information that may be pertinent for XMLdata feeds.

FIG. 8C illustrates example information that may be pertinent forpassword-protected files.

FIG. 8D illustrates example information that may be pertinent for filesstored on an FTP.

FIG. 9 shows an example embodiment that enables manual verification andcontrol over the mapping process.

FIG. 10 shows a screenshot of an example embodiment for importing a datafeed.

FIG. 11A shows a screenshot of an example embodiment of a user interfacefor configuring an Image module.

FIG. 11B shows a screenshot of an example embodiment of the userinterface for configuring an Image module, including a menu forselecting attributes from a content set.

FIG. 11C shows a screenshot of an example embodiment of the userinterface for configuring an Image module, including attributes of acontent set.

FIG. 12A shows a screenshot of an example embodiment of a user interfacefor configuring a page layout, including a blank preview screen.

FIG. 12B shows a screenshot of an example embodiment of the userinterface for adding a module onto a page layout.

FIG. 12C shows a screenshot of an example embodiment of the userinterface for configuring a page layout, including an un-configuredImage module.

FIG. 12D shows a screenshot of an example embodiment of the userinterface for configuring a page layout, including a configured Imagemodule.

FIG. 12E shows a screenshot of an example embodiment of the userinterface for configuring a page layout with several configured modules.

FIG. 12F shows a screenshot of an example embodiment of a generatedwebpage displayed in a web browser.

FIG. 13 shows a screenshot of an example embodiment of the userinterface for importing a data feed.

FIG. 14 shows a screenshot of an example embodiment of the userinterface for configuring the synchronization details of a data feed.

FIG. 15 shows a screenshot of an example embodiment of the userinterface for a marketplace, which allows users to add additionalmodules.

DETAILED DESCRIPTION

Described herein are example systems and methods for managing content.

An example adaptive content management system (CMS) is disclosed that isconfigured to interact with data without requiring a schema (althoughoptionally a schema may be used). The example content management system(CMS) enables the management and publishing of digital content. Incertain embodiments, the content can be in any digital form, such astext, images, videos, and/or audio. The CMS may publish content as pages(e.g., webpages) and/or export content through data feeds to otherapplications and user interfaces.

An example adaptive CMS will now be described. The adaptive contentmanagement system may auto-detect and map content and optionally storethe content in a schema-less data store. With a schema-based database,it may be challenging to push data into the database as the data has toperfectly fit the schema. By contrast, with a schema-less data store,data can be pushed directly to the schema-less data store without havingto massage the data to match a schema. A standardized user interface(UI) may be used for content (e.g., all content corresponding to theuser interface). The described example technique of interacting withcontent enables the content management system to dynamically generatewebpages based at least in part on imported content without requiringcustom plugins or custom software development (although such may beused). Optionally, when creating the design for the dynamicallygenerated webpages, users can interact with different imported datafeeds through a standardized UI without the need for additionalcontent-specific software.

An illustrative example case will now be described to provide context.In this example, a user manages her digital photographs through anonline image-management service. The user wants to display those imageson a separate portfolio website (operated by an entity different thanthe entity that operates the online image-management service), but shewants to continue to manage the photos through the image-managementservice. This situation is common among users of the image-managementservice, and so the image-management service may enable its users toexport their photographs through a data feed so that the photographs canbe displayed on their users' websites.

In this example, the user's portfolio website is built with aconventional CMS (although in other examples a non-conventional CMS maybe used), and so a relatively easy way for the user to import the datafeed is to look for a specific plugin that imports that specific datafeed and then displays that content on a webpage.

A plugin is also known by other names, such as extension, widget, ormodule. The exact model that each CMS uses to define a plugin may bedifferent, but in general, with respect to a CMS, the term refers toseparate software that extends the core functionality of a CMS. A pluginbuilt to work with external data typically handles both ingesting thecontent and displaying the content.

Unfortunately, with the conventional model, a plugin will typically workwith only one type of content having a specific schema. Therefore, ifthe user wants to import a data feed from a separate image-managementservice, then she must look for a different plugin that is designed forthat specific service. To understand why a conventional plugin will onlywork with one type of content, the following description of conventionalplugin development and how a conventional CMS works is provided.

A conventional CMS stores data in a database that uses a particularstructure or schema. To add custom content, such as a data feed from aseparate image-management service, conventionally a plugin developermust define a new database table that fits the schema of the content.Because this is a custom table, the developer must then build basicfunctionality that defines how users can interact with the content. Thisfunctionality is often summarized as create, read, update, and delete(CRUD).

The approach of a conventional CMS has some clear disadvantages,including some or all of the following:

-   -   To use a particular data feed, a user must find a plugin for        that particular feed.    -   If a plugin does not exist for a particular data feed, then to        use the feed, a user must develop a new plugin.    -   Even if a plugin exists, it will often perform certain        functions, but not all the functions a given user wants or needs        (e.g., a plugin might import images but not associated captions        or alt text). This situation conventionally requires custom        development to add the missing functionality.    -   Adding functionality to another developer's plugin might not be        possible or feasible if the code for the plugin is not available        to the user for modification.    -   The behavior of a conventional plugin is dependent on the        content that the plugin interacts with. So users must find a        plugin that has both the behavior that they want (e.g., formats        the content for display in a desired manner) and that works with        the content source, making it more difficult to find appropriate        plugins.    -   Using the conventional approach, the administration user        interface (UI) of different plugins may work differently. This        non-standardized approach makes the user experience confusing.        Because a given conventional plugin uses custom CRUD        functionality, the plugin developer must decide how the plugin        should interact with the administration UI of the CMS. For        example, suppose for plugin 1, developer X puts certain settings        in menu A and other settings in menu B. For plugin 2, developer        Y puts settings in menu C and requires that a user copy and        paste a specific code snippet onto each page. These inconsistent        approaches are commonly used by conventional content management        systems, and degrade the user experience.    -   If a CMS changes its administration UI in a new version, then a        plugin that was dependent on the previous version UI might no        longer work properly. By way of illustrative example, suppose in        version 1.0 of a CMS, developer X put certain settings in menu A        and menu B. If Version 2.0 of the CMS no longer supports menu B,        X's plugin can no longer be properly configured.    -   Plugins typically need to be updated (i.e., the plugin would        require additional software development) if the data feed        provider changes the structure of the feed. Because of the        nature of a schema, conventionally a plugin designed to work        with content of one particular schema will only work with        content that fits that schema.    -   When a CMS releases a new version, a plugin might not work with        that new version, and a developer would have to migrate the        plugin to the new version (i.e., the plugin would require        additional software development). Because a conventional CMS        stores and calls content in a particular manner, references to        that content must take into account that particular manner.        Therefore, if that manner of calling content changes, then a        plugin might no longer work with the CMS.

Often, content management systems or plugins support multiple feeds bysupporting common schemas. If the schema is broadly adopted, then theCMS can use one plugin to support many data feeds. However, even if manydata feeds are supported via a broadly adopted schema, there willtypically be many data feeds that are still not supported and would needdifferent plugins.

Below, a Program Listing section is provided that includes severalillustrative example markups for three different example data feeds: anExtensible Markup Language (XML) feed, a JavaScript Object Notation(JSON) feed, and a comma-separated values (CSV) feed. In this example,these three data feeds all describe the same information, but thesethree feeds are structured using three different respective markuplanguages. Using the conventional approach, a plugin designed for theschema of one feed would not work with the other feeds.

In an example embodiment, a content management system (CMS) as describedherein can accept and display content regardless of schema byautomatically detecting and mapping the schema of imported content(optionally without user intervention) and then by storing the contentin a schema-less database. By not committing to or being limited to aparticular type of content, the CMS can expose the content to a plugin(e.g., widget, module, or extension) either through an API (applicationprogramming interface) that contains methods for calling the content orby injecting the content into the module in the form of a data type suchas an array. Because each type of content may optionally be referencedin the same way, the CMS can use a standardized user interface (UI) formultiple plugins or every plugin (e.g., widget, module, or extension).Optionally, the CMS also enables the user of the CMS to determine ifcontent is appropriate for the plugin. Thus, users do not have to createa schema defining the content. With this treatment of content, pluginscan work with and receive imported content (e.g., any imported content),regardless of source or schema.

Accordingly, several optional advantages (not all of which need beachieved by a given embodiment) of one or more aspects are as follows:

-   -   Any plugin (also known by other names such as a widget, module,        and extension) is able to accept any imported content without        custom software development, and will attempt to render such        content. The user is enabled to determine if the way the content        is rendered is as the user intended.    -   Users without software development abilities can combine several        different data feeds for use on their webpages (or otherwise)        without installing custom plugins and without employing a        software developer.    -   Changes to the structure of a data feed may be auto-detected and        mapped without requiring additional software development to        conform to such changes.    -   A CMS can use a standardized user interface (having the same        look and feel) for many or all plugins offered by the CMS,        including custom plugins developed by third parties and        submitted to the CMS for use by other users. For example, a        third-party developer may specify to the CMS which fields are        needed (e.g., a text field called “name”), and the CMS        determines the appearance of the fields (i.e., the UI), how        content will be entered into the fields (e.g., via drop-down        menu, text field, check box), and what types of content will be        allowed (e.g., static text or references/links to imported        content). The third-party developer may then refer to the        content in fields, for example, using methods in an API or        references to a data type (e.g., an array).    -   The content of some or all of an entire website can be changed        by just synchronizing a different data feed—also, without the        need for additional software development.

An example embodiment of a process of importing and rendering contentfor a given page (e.g., one or more webpages) with an adaptive contentmanagement system (CMS) is illustrated in FIG. 1. The example processwill be described in greater detail with reference to other figures.

Referring to FIG. 1, at state 100, the CMS imports and maps content froma data (content) feed specified by a user. A state 102, a determinationis made as to whether a page layout (for the page which will use contentfrom the feed) is already been configured. The page layout describeswhich content is included in a generated page. If a page layout is notalready configured, then a page layout is configured at state 104. Oncethe page layout is configured, optionally the content can besynchronized at state 106; for example, a determination may be made asto whether the feed has been updated since it was last imported. If thefeed has been updated, then the content for the page may beupdated/synchronized. With the content imported and the page layoutconfigured, at state 108 the CMS may dynamically generate pages (to berendered on a user terminal, such as a browser equipped computingdevice) based at least in part on the content from the feed.

Import Content

An example import process (corresponding to state 100 in FIG. 1) isillustrated in FIG. 2. To identify the feed, the adaptive CMS usesinformation about the feed 200, such as the location of the feed (e.g.,the URL or local directory) and information on how to access the feed(e.g., username, password, port, server, and/or path). For example,optionally the location and/or access information may be received from auser, where the information may be entered by the user in fieldspresented by a data feed specification user interface. Otherembodiments, such as those discussed below and illustrated in FIG. 8A-D,may use more or less feed information. Optionally, the CMS may verifythe feed information to determine whether it is valid or not. Forexample, if, when attempting to retrieve data from the feed, the CMSreceives an HTTP 404 Not Found error, then the CMS determines that theURL provided is invalid. Optionally, if the information is determined tobe invalid, the user may be informed via a notification user interfaceand the CMS may prompt the user to enter correct feed information. Ifthe CMS receives new information from the user, the CMS may again verifythe information.

If the feed information is valid, at state 202, the CMS can beginmapping the content. By way of example, the content may be in the formof a flat file, XML, JSON, CSV, and/or other form.

If the data is well formed (has proper syntax), then the CMS canaccurately map the data 208; otherwise, the process can optionallyreturn to the input state 200. Optionally, certain embodiments may guessor infer the appropriate structure of malformed data (e.g., HTML codewith syntax errors). For example, the CMS may search for a specificpattern (e.g., using a regular expression) of malformed markup (e.g., anopened but not closed element, unescaped character entities, malformedHTML tags, improperly nested HTML elements, etc.). Optionally, the CMSmay correct certain malformed date (e.g., by replacing the malformedmarkup (e.g., by closing the element before the next element isopened)). Generally, with respect to a markup language, well-formed datacomplies with the basic rules/syntax of its markup language (e.g., allopened elements are also closed, elements are properly nested so thatthey do not overlap, proper delimiters are used, etc.).

Conventional approaches for automatically mapping data force content tofit a particular schema. Such conventional approaches fail to alleviatedisadvantages mentioned previously. Optionally, rather than using suchconventional approaches, the example embodiment illustrated in FIG. 2uses data mapping to create a CMS database based at least in part on therelationship of the imported data (e.g., see the example ProgramListings below). So once mapped, the data is optionally stored in aschema-less database 210 that does not rely on a fixed data model. Thus,the organization of the database can adaptively change in the future inresponse to changes in the structure of the content. An example processcomprises storing the imported content through key-value stores (e.g.,highly optimized key-value stores, document-based store that storesdocuments made up of tagged elements, etc.), such as in the datastructure of a programming language (e.g., an associative array),although other techniques may also be used.

For example, the illustrative Program Listing below includes anassociative array based on the relationship of the data in any one ofthe feeds shown in the Program Listing.

Thus, using key-value stores, data may be stored in a programminglanguage data type or an object, and so a fixed data model is notrequired. Indeed, utilizing this technique of content import andstorage, the three different example data feeds shown in the ProgramListing section would each be stored and referenced in the same waybecause the relationship of the information (and the information itself)is the same across all three data feeds.

It is understood that certain embodiments may not utilize mapping (e.g.,where the user defines his or her own content set rather than using athird party feed).

Configure a Page Layout

In an example embodiment, to use imported content, the adaptive CMSapplies the content set model, but other models may also be used. Forexample, another suitable model uses the columns and rows technique,which represents data like a spreadsheet: separating data intoindividual rows that are defined by columns. For example, in aspreadsheet of user information, each user might be represented by aseparate row, and the columns that define each user might include Name,Email, Password, and Phone number columns. A page layout can then beconfigured to use certain columns. The page layout may be used togenerate dynamic web pages when passed different rows. The content setmodel (described below) is similar to the columns and rows model, butthe content set model is more abstract, and it, therefore, has certainadvantages for conceptualizing complexly organized data. For example,deeply nested elements where one element is actually an array (e.g., anarray of images) of arrays (e.g., alt text, link, and URL of the image)may be utilized.

The content set model comprises a high-level organization, an example ofwhich is illustrated in FIG. 7A. A given imported data feed is organizedinto a separate content set 700. For example, a data feed for a blogmight be a content set. The content set is then organized into items702. For example, if the content set is the feed for a blog, then agiven item may correspond to an individual blog post. Each item is thenorganized into one or more attributes 704. For example, if each item isan individual blog post, typical item attributes might, in this example,include title, author, posted date, categories, and blog body.

In the content set model, each item of a given type has the sameattributes, but the value of the attributes might be different acrossitems. Consider an example of a content set based on a blog: each blogpost (each item) has a title (an attribute), but the value of the titleis probably different for each blog post—the value of the title for oneblog post might be “How to Properly Steep Peppermint Tea,” and the valueof the title for another blog post might be “The Secret to Preparing AlDente Pasta.”

Using the model shown in FIG. 7A, attributes of any imported content canthen be used to dynamically generate pages, such as web pages. The pagegeneration process is described in greater detail below. In the exampleembodiment illustrated in FIG. 5, the layout of a page is determined, atleast in part, by assigning attributes (such as 504, 506, and 508) tomodules (such as 502). This page layout is stored by the CMS so that therenderer (which is described later) can access it in order to properlygenerate a page. In the content set model in the context of thedisclosure herein, a module (also referred to by other names such as aplugin, widget, or extension) is software that interacts with the CMS toperform a specific function such as display text or an image. Modulesmay be used to generate each element of the page layout. For example,text on the page might be generated by a Text module, videos on the pagemight be generated by a Video module, and an interactive map on the pagemight be generated by a Map module.

In this example embodiment, each module is encapsulated to first acceptinput in high-level terms (e.g., text, image, or HTML), to execute codethat transforms the input in a particular way (e.g., transform a URL ofan image into HTML describing the image), and to output thetransformation. A given module in this example does not expect theoriginal content to fit a particular schema or to be from a particularsource, and so a module can accept any attribute of a given item type ofany content set.

This example process also enables a module to interact with a given itemattribute through a standardized administrative user interface (UI). Asdescribed earlier, the conventional approach requires the developers ofcustom modules (or plugins) to create their own database table and CRUDfunctionality, which prevents a conventional CMS from using astandardized administrative UI for custom modules. However, with theadaptive CMS, because modules are not dependent on specific content andbecause the content conforms to the content set model (as describedearlier and illustrated in FIG. 7A), the adaptive CMS is able to createa standardized UI for each module, including for custom modules designedby third-parties. For the CMS to create the UI, the developer of amodule gives the CMS a high-level description about what type of fieldswill be needed. For example, this information may include type ofcontent (e.g., image, text, integer), the name of the element, a labelto appear in the UI, and so on. The CMS may start with a templatedefining the appearance the administrative UI, and then the CMSpopulates the template with this descriptive information. This way theCMS creates a UI that is both customized to the needs of each module,and standardized across the modules.

The CMS may host or provide access to a library of modules from which auser can select and configure to control the look and feel of data(accessed from data sources via the module) that will be displayed on apage. An example screenshot of the interface for the library is shown inFIG. 10. The example shows some modules grouped into categoriesaccording to use 1000, other uncategorized modules 1002, and a buttonthat, when clicked, displays additional modules 1004. For example, thelibrary may include an image slide module, a blog module, a news feedmodule, a financial data module, a sports score module, a video playlistmodule, a graphing module, a responsive menu module, a shopping cartmodule, a map module, a search module, a text module, a navigationmodule, a markup module, a layout module, a content module, an accordionmenu module, a carousel module, a share page or content module, a socialmedia module, and/or other modules.

As will be discussed below, the user can configure a given module fortheir specific use without having to code the module and without havingto know the schema used by the data source. Thus, user configuration ofa module, rather than user coding of a module, enables a module to beused with multiple data sources and for different pages. For example,menu selections may be provided (e.g., via a drop down menu orotherwise) for various item attributes from which the user may select. Agiven module may be used with a variety of unrelated content sources. Byway of illustration, the same image slide module (used to present aslide show of images on a webpage) may be used to obtain images feedsfrom multiple data sources (e.g., Picasa®, Flickr®, Facebook®,Photobucket®, etc.). The user is spared from learning the particulars ofthe data sources interface or schema, and from having to obtain code orask for customization from the data source. Further, as noted above,optionally the various modules available from the library have the samelook and feel with respect to the user configuration interface. Having aconsistent look and feel makes configuration of the modules lessconfusing and more efficient for the user. Optionally, the CMS mayinclude a module uploading interface which enables users to contributemodules to the library for use by other users.

To add content to a module, users associate attributes from a contentset with the fields of a module. One example module is the Image module.For example, FIG. 11A illustrates an image module configuration userinterface with common fields that might be used for an Image module,such as:

-   -   Current Image 1100. For example, users may set this field to an        attribute that contains the URL (or other locator) of an image.    -   Image drop-down menu 1102. Users may use this menu to manually        select an image that they had previously uploaded to the site.    -   Alternate Text 1104. If the image cannot be displayed, then the        text entered in this field is displayed instead.    -   Link 1106. Once the website is rendered, if visitors click the        image, they will be directed to the URL entered in this field.    -   Apply button 1110. This button allows users to save        configuration settings.

A “remove widget” control is optionally provided. In response to a useractivation of the “remove widget” control, the CMS will delete themodule. A “reset” control is optionally provided. In response to a useractivation of the “reset” control, the module fields will be reset totheir initial state (e.g., empty).

Optionally, a preview mode is provided where, in response to a userconfiguration and user preview instruction, the CMS causes a preview ofhow a page (or a portion thereof) will look (e.g., when rendered by abrowser) given the current user-specified module configuration. FIG. 12Aillustrates an example instance of a preview user interface before auser has added any widgets. A library of widgets 1200 (which is alsoseparately represented illustrated in FIG. 10) that users can use tobuild the page layout is illustrated at the top of the user interface. Anavigation menu 1204 to navigate the CMS is shown on the left of theuser interface. The preview itself is represented by layout area userinterface 1202. FIG. 12D depicts the example preview screen (with thenavigation menu cropped out) after a user has added and configured anImage module 1206.

In the example embodiment illustrated in FIG. 3, the user interface of amodule 300 has three fields: field 1 302, field 2 306, and field 3310—although, the number of fields may vary between modules. Forexample, a module for an image might have four (or other number of)fields: image, alt text, image link, and caption. To facilitate thegeneration of dynamic pages, the fields accept references to attributes,as shown by 304, 308, and 312. A module may determine how content isdisplayed/rendered. For example, if the module is configured to displayan image and associated text (e.g., alt text and a caption), the modulemay determine the resolution the image will be displayed in, the textfont, the text font size, and the position or other formatting of thetext. The specifics of dynamically generating a page are described ingreater detail below.

While FIG. 3 has attributes already selected for each of its fields, theexample embodiment shown in FIG. 4 uses a menu 400 to illustrate thatany available attribute can be applied to any of the fields. Forexample, the function of a given module could be to display an image(from a content source). In this example, one field might accept anattribute containing a URL for the image and another field might acceptan attribute containing a caption for the image. Thus, rather thanrequiring a user to program a module for a specific content source, theuser may specify which attribute is to be applied to which field via aneasy to use menu interface (by selecting a desired menu entry), wherethe menu choices for each field may include all the attributesapplicable to the module. For example, the menu selections for a moduleconfigured to display an image may include: image, link, and caption.

The module may optionally treat each attribute the same, so the userdetermines and specifies which attribute is appropriate for which field.For example, if one field is designed to accept the URL for an image, auser can select an attribute (from the menu 400) that contains thecaption for that image. In that case, the module would still use theattribute, and the module would attempt to display an image using thecaption as the URL. The resulting HTML would most likely not display animage. While this method has the possibility to, for example, createbroken images, the method also allows the content of any data feed towork with any module.

In an example embodiment, for the CMS to implement the administrative UIof a module, a module communicates to the CMS an identification of whathigh-level content it needs (e.g., text for two text fields and an imagefor one image field), and the CMS applies a standard UI (as describedearlier and as illustrated in FIG. 3). Optionally, along with thefields, the module might also communicate clarifying information such asthe name of the fields (e.g., Caption, Alt Text, and Image), thearrangement of the fields (e.g., first Image, then Alt Text (alternativetext associated with an image that serves the same purpose and conveysthe same or corresponding essential information as the image), and thenCaption), and tooltips text (e.g., “Alt Text is alternative text thatwill be displayed if the image cannot be rendered”). As is understood, atooltip may be in the form of a hint or prompt that appears when a userhovers a cursor/pointer over and/or adjacent an item for a specifiedperiod of time.

FIG. 5 illustrates an example of a page layout 500 that includes twomodules (although fewer or additional modules may be added by a user).While FIG. 3 shows the UI that enables a module to use an attribute,FIG. 5 illustrates how modules display content based on thoseattributes. The modules can be arranged in any order, and each modulemight have a different functionality. For example, if the original datafeed contained URLs for images, then one module might use the URLs todisplay the images, while another module might use the URLs to displaylinks to the images. The module determines how the data is displayed.The CMS provides a user interface via which the user can select modulesfrom a module library and drag and drop the modules onto the page layoutinterface to specify where the data from a given module is to bedisplayed on the page. FIG. 12B illustrates an example process ofdragging an Image module 1208 onto a page. The module will be insertedat the location indicated by outline 1210. In FIG. 12C, the Image modulehas been placed on the page. A gray box and outline 1212 indicate theplacement of the module. The CMS will then store the correspondinglayout in memory.

The example page layout in FIG. 5 comprises two example modules: 502 and510. In this example, module 502 is set to use three attributes: 504,506, and 508. Module 510 is also set to use three attributes: 512, 514,and 516. In this example, module 502 is configured to display theattributes as circles and module 510 is configured to display theattributes as squares. While each module uses a different method todisplay these attributes (module 502 displays the attributes as circlesand module 510 displays the attributes as squares), the content that themodules display is based on the content of each attribute.

Referring to the blog example described earlier, if a page layoutrepresents a blog post, then one module might display a heading by usinga title attribute, another module might display an author's name usingan author attribute, and another module might display the text of theblog using a body attribute. The module may display a given attributeaccordingly (e.g., the title may be displayed first with a first fontsize, the author's name may be displayed centered just beneath the titlein a second font size that is smaller than the first font size, and theblog body may be displayed beneath the author's name in a third fontsize).

FIG. 7B illustrates an embodiment that contains an identifier (e.g., aunique ID 706) for each item. The ID can be used as a parameter toreference each item 702, but other techniques for referencing aparticular item may also be used. So while the page layout 500 specifiesparticular attributes, the layout does not specify a particular item,meaning that one page layout can be used to display the attributes ofany item in a content set. Using the previous blog example, a blog postlayout can be created once using one or more modules, and then the sameblog post layout (the same modules) may be used to display each blogpost in a content set.

Generate a Page

An example page generation process will now be described with referenceto FIG. 6, which illustrates an example page layout technique that maybe executed by the CMS to generate a page (e.g., a webpage). A request600 is sent to the renderer 610. Typically, this request would be sentby a web browser or other requester hosted on a user terminal (e.g., amobile communication device (e.g., a mobile phone), a desktop computer,a laptop computer, a tablet computer, a smart television system, etc.)over a network (e.g., the Internet) to the renderer 610 which receivesand processes the request. The renderer 610 may optionally be hosted ona system separate from the content source (physically separate from andoperated by a different entity than the content source), or the renderer610 may be hosted on the same system as the content source. The renderer610 may comprise a software engine, which may be part of the CMS.

Referring again to FIG. 6, the renderer 610 receives several requests(e.g., from the user browser): requests 602, 604, 606, and 608 in thisexample. In this example, each request includes a unique ID, which is arequest for a particular item. For example, request 602 includes“id=triangle,” which is a request for the item with the unique ID equalto “triangle.”

As described earlier, the ID 706 determines, at least in part, what item702 is displayed, and the page layout 612 (defined using one or moremodules) determines what attributes 704 to display and how to displaythose attributes. For example, request 602 is a request for the itemwith the ID “triangle.” As item 616 (corresponding to the “triangle”item) illustrates, that item has several attributes, and the page layout612 requests three of these attributes (which may be fewer than thetotal number of attributes associated with the item).

The renderer 610 then generates webpages 624 based at least in part onthe requested items 600 and the page layout 612. For example, therequest for “id=triangle” 602 causes the renderer 610 to generate awebpage represented by generated page 626.

With this process, a single page layout can be used to generate multiplewebpages with different content. The data feeds shown in the ProgramListing section would each generate one content set with three items,and one page layout could therefore be used to create three pages inthat instance.

Optionally, the page layout, the renderer, the code for the modules,and/or the generated webpages may reside on the CMS.

Process Overview of Example Embodiments

To further elucidate the process of the first example, this section willdescribe a hypothetical example where a user imports a data feed,configures a page layout, and where the renderer generates a webpage. Toprovide additional clarification, this section will also referenceexample screenshots of the user interface (UI) for an example embodimentof the CMS, but other UI designs are also suitable.

In the hypothetical example, a user wants to import an XML feed thatcontains a list of products. This XML feed is shown in the ProgramListing section. The user then wants to use this feed generate anindividual webpage for each product.

Import

To ensure that the data feed is accurately mapped, the user provides theCMS with following details about the feed (a screenshot of this examplestep is shown in FIG. 13):

-   -   Name 1300. The Name enables a user to later distinguish between        multiple content sets. Because the name optionally is only used        to provide clarity to the user, the name could be any word,        phrase, number, etc. In the hypothetical example, the user used        the name “Products,” so the CMS will refer to the feed as the        “Products” content set.    -   File Format 1302. The File Format specifies how the file is        encoded and what markup language is used. In the hypothetical        example, the feed is in XML format.    -   Location 1304. The Location field specifies how the file is        stored (e.g., if the file is stored on an FTP, on the web, or        locally). In the hypothetical example, the feed is located on        the web.    -   XML Document Element 1306. As described previously (and as shown        in FIG. 7A), the CMS may organize data feeds into separate        items. This field asks for the document element that surrounds        each item in the file. In the hypothetical example, this element        is called “tea.”    -   ID 1308. As described previously (and as shown in FIG. 7B), each        item may be assigned a unique ID. This field asks for the name        of the element/field in the source data containing the unique ID        (which can be used to uniquely identify the record). In the        hypothetical example, this element is called “id.”    -   URL 1310. The URL is the location of the data feed. In the        hypothetical example, the URL is        “http://example.com/feeds/teas.xml.”    -   Username 1312. If the feed is password protected, a username        might be required, and so the user name may be inserted into        this field. In the hypothetical example, the feed is not        password protected, so this field is left blank.    -   Password 1314. If the feed is password protected, a password may        be required, and so the password may be inserted into this        field. In the hypothetical example, the feed is not password        protected, so this field is left blank.

Once the details have been entered, the user clicks the “Create” control1316 to begin the mapping and import process (as shown in FIG. 2). Thepreceding are optional features details of an example embodiment, anddifferent, more, or fewer features may also be used. Additionaldiscussion of example features and details that may be beneficial to theimport step is provided below in the Additional Example Embodimentssection.

In this example, the CMS maps the XML data feed so that there are threeitems, because the data feed has three tea elements, and each item hasthe following attributes:

-   -   id    -   name    -   caffeine    -   type    -   Description    -   price    -   image    -   thumb

Each attribute corresponds to an element in the data feed. As discussedabove, the CMS optionally stores the data in a schema-less database(see, e.g., block 210, FIG. 2), and an optional storage method involvesstoring the imported content in key-value stores such as in the datastructure of a programming language (e.g., an associative array), butother methods may be used.

Once the data feed has been mapped and stored as the “Products” contentset, the CMS displays a configuration user interface to the user (anexample of which is shown in FIG. 14), but other methods of confirmingthat the content set successfully imported may be used. Theconfiguration screen provides the user with information about the lasttime the content set was updated via an update status user interface1406.

Because the content of the feed is controlled externally to the CMS, thecontent of the feed and the content stored in the CMS might becomeunsynchronized. To keep the content synchronized, the user can either(1) manually synchronize the content by manually activating a “run batchupdate” control 1416 or (2) set a reoccurring update via an updatescheduling user interface 1408-1414, which enables the user to specify astart time and the update period (e.g., hourly, every 4 hours, daily,weekly, etc.). The manual and auto-synchronization features are furtherdiscussed below in the Additional Example Embodiments section.

Using the example configuration user interface illustrated in FIG. 14,the user can configure how the CMS treats updated content. For example,if the Add to Existing Data Set function is enabled (via control 1400),tea elements deleted from the feed are not deleted from the synchronizedcontent set, but any updates to tea elements (e.g., if a description ischanged) are updated in the synchronized content set. However, ifinstead, for example, if the Replace Data Set function is enabled (viacontrol 1402), any tea elements deleted from the feed are deleted in thesynchronized content set.

Additionally, the configuration user interface illustrated in FIG. 14,enables the user to adjust/modify the details that she entered initiallyvia fields 1300-1314 in case any of the details of the feed change inthe future. Optionally, the user may save such modifications byactivating the Save control 1404, but other methods for saving changesmay be used.

Configure a Page Layout

Once the feed is imported, the user can configure a page layout to usethe imported content. A depiction of a blank, un-configured layout areauser interface 1202 is shown in FIG. 12A. To build the page layout, theuser uses modules. As described earlier (and as shown in FIG. 5),optionally every element in the page layout is a module. For example, toadd an image to a page, the user would add an Image module, and thenconfigure the module, through its UI, to accept the URL (or otherlocator) of an image (which is described in more detail later and shownin FIGS. 11A-C). To add an interactive map, for example, the user wouldadd and configure a Map module.

As described earlier (and illustrated by FIGS. 3-4), optionally eachmodule will accept attributes from any content set, which means that anyimported data feed may provide these attributes. Therefore, whenselecting a module, the user looks/searches for a module that performs aparticular action, such as a module that displays text or a module thatdisplays an image.

Some modules are available by default, and the user can select thesemodules from the toolbar 1200 on the same screen as the page layout areauser interface 1202. Referring to FIG. 15, a user interface 1502 isoptionally provided via which the user can also select and obtain othermodules from a widget marketplace. In this embodiment, the widgetmarketplace contains modules created and submitted by third-partydevelopers. The 1200 toolbar and widget marketplace 1502 are exampletechniques which may be used to provide users with a variety of modulesfrom which to select, but other techniques may also be used.

Referring to FIG. 12B, in this example, to build the page layout, theuser starts by dragging an Image module 1208 from the toolbar 1200 ontothe page layout area 1202. Referring to FIG. 12C, the inserted andun-configured module 1212 is shown. The user then configures thesettings of the module 1212, so that it accepts the image attribute fromthe Products content set the user created earlier. An example processfor configuring the module may utilize the user interface as shown inFIG. 11A-C.

Referring to FIG. 11A, the user selects the Current Image field 1100(e.g., by moving a cursor to, or pointing at the Current Image field1100). Referring FIG. 11B, the CMS presents the user with an attributemenu 1112 containing some or all attributes of some of all content sets.In this embodiment, the user can cause the CMS to present the attributemenu 1112 by pressing a key (e.g., the down-arrow key), but othertechniques for bringing up the menu may also be used. In this example,the user selects the Products: image attribute 1114 (i.e., the imageattribute of the Products content set). FIG. 11C shows the Products:Image attribute 1116 entered in the Current Image field 1100. Theexample Image module has other fields and options (1104-1108), and inthe Alternate Text field 1104, the user has selected and instructed theCMS to add the Products:name attribute 1118 as similarly discussed abovewith respect to the addition of the image attribute 1114. The fullyconfigured example Image module 1206 is shown in FIG. 12D.

The user may add and configure other modules in the same or other mannerto use the other attributes of the Products content set. Because eachmodule is not dependent on a particular data feed, the CMS is able touse a similar UI for each module.

The fully configured example page layout is shown in FIG. 12E. Thislayout combines several modules. For example, the image of a tea bag1206 is provided via the Image module described earlier (with referenceto FIG. 11A-C), and the “PEPPERMINT” heading 1214 is provided via aHeading module that is using the Products: name attribute.

Generate a Page

Once the user publishes the page layout, the CMS is configured togenerate a webpage for each item in the Products content set. To view awebpage for a particular item, a visitor directs his/her browser to theURL of the page layout (e.g., http://example.com/product-details),including the unique identifier for the particular item (e.g., id=1).For example, if the URL of the page layout that the user created earlier(as shown in FIG. 12E) is http://example.com/product-details, then toview a webpage for the Earl Grey item of the Products content set, auser would visit: http://example.com/product-details?id=1. The Earl Greyitem has a unique identifier of 1 because that is the id that is definedin the original data feed (as shown in the Program Listing).

FIG. 12F shows the example Earl Grey webpage when viewed in a browser.The URL 1216 indicates that the browser requested the item with an idequal to 1. As described earlier (and as shown in FIG. 6), the request600 is transmitted to the renderer 610, which passes the request to thepage layout 612. The page layout passes the request to the individualmodules, which each call for attributes of a particular content set.

As noted, in the example shown in FIG. 12A-E, the modules are configuredto use attributes of the Products content set. The id requested is 1,which corresponds to the Earl Grey item. Therefore, the modules (asshown in FIG. 5) use content from the attributes of the Earl Grey itemand the generated webpage 624 is for Earl Grey tea 1218.

Additional Example Embodiments Detect the File Format

While content of any schema can be imported into the adaptive contentmanagement system (CMS), the CMS is optionally configured to determinehow to decode and read the format of imported content. The format refersto the manner in which the data feed was encoded and the markup languageused to create the data feed. Examples of possible file formats includebut are not limited to Extensible Markup Language (XML),character-separated values (CSV), JavaScript Object Notation (JSON), andExcel Binary File Format (XLS). Understanding the semantics of theencoding method and markup language of imported content enables the CMSto properly map that content.

Various techniques may be used to communicate the file format to theCMS. In an example embodiment, the CMS can specifically request thisinformation (e.g., from the content source or the user) when importing adata feed. This embodiment is shown in FIG. 8A, where the content setinformation included file format 804. The CMS can then receive andutilize the file format information.

Optionally, the CMS is configured to detect the file format of a datafeed automatically. For example, information about the file format mightbe embedded in the metadata of a data feed which may be read by the CMS.The extension of a data feed may also indicate its format, and so theCMS may determine the format based on the extension. Optionally, the CMScan compare patterns in the data encoding against a database of knownpatterns to determine the encoding method. Certain embodiments may useany combination of the foregoing techniques to determine the format.

Data Feed Details

In one or more embodiments, certain details about an imported data feedmay be passed to the CMS, as will be discussed with reference to theexamples illustrated in FIGS. 8A-D. Many variations and modifications tothe requested details are possible, and the details described here andillustrated in FIGS. 8A-D are to be understood as being among otheracceptable examples. The content set information 800 representsinformation about the data feed that the CMS requests before beginningthe import process 100. This information enables a user to control howthe feed is mapped.

As shown in FIG. 8A, in this example, the content set informationincludes the following details (it being understood that other examplemay include different details):

-   -   Name 802 (e.g., a unique name that identifies the content set)    -   File format 804 (e.g., the manner in which the data feed was        encoded and the markup language used to create the data feed)    -   Location type 806 (e.g., webpage, FTP, or local directory)    -   Location of file 808 (e.g., the URL or directory where the file        is stored)    -   Unique ID 810 (e.g., the name of the unique identifier field in        the data feed)

Another example embodiment of content set information is shown in FIG.8B. If the file format of the data feed is an XML file, then requestingand receiving the name of the root element that surrounds each item 812enables the CMS to more accurately map the data feed.

The example embodiment of content set information illustrated in FIG. 8Cincludes two optional fields: username 814 and password 816. Thisembodiment handles the case of password-protected data feeds.

The embodiment of content set information shown in FIG. 8D includesadditional fields to handle the case of a file stored on an FTP server.Additional pertinent information includes:

-   -   Server 818 (the location of the sever that stores the data feed)    -   Port 820 (the number of the port that should be used to open a        data connection)    -   Path 822 (the location where the file is stored on the server)

Synchronization and Auto-Synchronization

As illustrated in FIG. 1, once a feed is imported into the CMS 100, atblock 106, the feed may be synchronized. In an example embodiment, aspart of the synchronization process, the CMS will reimport the feedusing any feed details that have already been entered. There are variousreasons for synchronizing an already imported feed, but one optionalreason is to ensure that the imported content matches the currentcontent in the data feed.

Optionally, the process of synchronizing content involves synchronizingin response to a manual instruction. For example, a user accessiblesynchronization control may be provided. If a user wants to synchronizecontent, then the user may select the synchronization control, and inresponse to detecting the selection of the synchronization control, theCMS imports and maps the latest content from the data feed. Optionallyin addition or instead, a user may specify a synchronization schedulewhich may be received and stored by the CMS. The CMS may then performthe content synchronization according to the schedule. For example,synchronization could be set to occur at a designated start time and/orat designated intervals (e.g., once a minute, once an hour, or everyTuesday at 5:00 PM).

By enabling users to synchronize an imported feed, users are enabled tomanage content residing outside of the adaptive CMS. For example, a usercan manage photos through an image-management service and then use anadaptive CMS to display the photos on a separate portfolio website byregularly synchronizing the CMS with a feed from the image-managementservice. By way of further example, a user could upload a new photo tothe image-management service, and the adaptive CMS may generate a newwebpage based on the new photo the next time the CMS is synchronizedwith the feed.

Multiple Content Sets on One Page

The example page rendering process illustrated in FIG. 6 may be utilizedto render one or multiple content sets on a page. As illustrated, a pagelayout 612 displays different content depending on the ID in a request,such as in request 602 (ID=triangle). In this example, only one contentset per page layout is used. Optionally, multiple content sets per pagemay be used. An example process enabling multiple content sets per pageto be used comprises having a given page include arrays of content setand ID pairs, but other techniques may also be used.

Friendly URLs

While an example URL for a webpage might look likehttp://example.com/product-details?id=1, a webpage may optionally begenerated using a friendly URL (a Web address that is easy to read andincludes words that describe the content of the webpage). An example ofa friendly URL is: http://example.com/product-details/earl-grey. Onesuitable embodiment of this process involves mapping a friendly name(e.g., earl-grey) to the unique ID (e.g., 1), for example, using a datastructure such as an associative array.

Manual Mapping

Auto-mapping of content, as described above with reference to FIG. 1,might not be without error. To address such an eventuality, an exampleembodiment, such as that illustrated in FIG. 9, enables manualverification and control of the mapping process. With each content set900, the attribute type 904 for each attribute 902 can be selected bythe user and the selected is received and stored by the CMS for lateruse in the mapping process. Optionally, a menu 907 containing possibleattribute types 908-926 (string 908, float 910, double 912, byte 914,short 916, integer 918, long 920, date 922, Boolean 924, binary 926) canbe provided by the CMS to aid the user in selecting an appropriateattribute type, but other attribute types may also be used.

In the example embodiment shown in FIG. 9, the user may manually specifyhow the attribute is stored via menu interface 906 (e.g., which enablesthe user to specify whether the attribute is to be indexed, ignored, ornot analyzed). For example, if a data feed contains an unnecessaryattribute, then a user might choose to instruct the CMS to ignore theattribute by selecting the ignored menu selection 932. Optionallyinstead, a user can instruct the CMS to index the attribute by selectingthe index menu selection 930, to make it discoverable by other widgets,or a user could set the attribute to non-analyzed by selecting thenon-analyzed menu selection 934 to force the attribute to be treated asa whole by the CMS and prevent it from being broken down through furtherprocessing.

Multi-Tenant Development

In an example embodiment, if each module is properly encapsulated toaccept content in only high-level terms (e.g., text, image, or URL) andto execute independently of other modules, then one or more modules canbe incorporated within another module (e.g., without requiring an opensource environment which user are provided with the ability to modifythe source code).

For example, suppose developer A wants to create a module that displaysa heading, followed by an image, followed by text. If each module isproperly encapsulated as described earlier, instead of hand coding theentire module, A could just incorporate a premade heading, image, andtext module. If developer B, wants to expand on A's module by adding avideo, then B could just incorporate A's module with a premade videomodule.

This type of customization conventionally requires sharing source code,but with proper encapsulation and a content agnostic approach asdescribed herein, multi-tenant modules of this type may be performedwithout sharing any source code.

Generated Output

While the example CMS optionally eventually generates a webpage, the CMSmay be configured to generate other types of data in any form, such as,by way of example, XML, JSON, or CSV data feeds. The ability totransform the data and the method by which the data are transformed arenot dependent on the eventual output.

Involving Additional Systems

While a single CMS may optionally be used to execute the process fortransforming a data feed into a website, optionally different systemsmay be utilized at different stages. In an example embodiment, onesystem may be used to import the content, another separate system may beused to configure the page layout, and a third system may be used todynamically generate the content. The use of multiple systems mayprovide the same or similar ability to transform the data feed using thesame or similar processes as the single system embodiment.

The methods and processes described herein may have fewer or additionalsteps or states and the steps or states may be performed in a differentorder. Not all steps or states need to be reached. The methods andprocesses described herein may be embodied in, and fully or partiallyautomated via, software code modules executed by one or more general orspecial purpose computers comprising one or more hardware computingdevices. The code modules may be stored in any type of non-transitorycomputer-readable medium or other computer storage device. Some or allof the methods may alternatively be embodied in whole or in part inspecialized computer or state machine hardware. The results of thedisclosed methods may be stored in any type of computer data repository,such as relational databases and flat file systems that use volatileand/or non-volatile memory (e.g., magnetic disk storage, opticalstorage, EEPROM and/or solid state RAM). The servers discussed hereinmay include (or be hosted on systems that include) network interfacesconfigured to receive document requests (e.g., webpage requests from abrowser) and to transmit responses to the requester. The servers andother devices described herein may optionally include displays and userinput devices (e.g., keyboards, touch screens, mice, voice recognition,gesture recognition, etc.).

Many variations and modifications may be made to the above-describedembodiments, the elements of which are to be understood as being amongother acceptable examples. All such modifications and variations areintended to be included herein within the scope of this disclosure. Theforegoing description details certain embodiments. It will beappreciated, however, that no matter how detailed the foregoing appearsin text, the invention can be practiced in many ways. The use ofparticular terminology when describing certain features or aspects ofcertain embodiments should not be taken to imply that the terminology isbeing re-defined herein to be restricted to including any specificcharacteristics of the features or aspects of the invention with whichthat terminology is associated.

Optional Advantages

From the previous description, a number of optional advantages of someembodiments of adaptive content management become evident. A givenembodiment may provide one or more of the following advantages:

-   -   A user can import content without having to consider if its        schema is compatible with the content management system (CMS);        therefore, a user does not have to search for particular        feed-compatible widget/module before using a feed.    -   Plugins are optionally not designed for or limited to specific        feeds, and so users are more likely to find modules with the        behavior that they desire. For example, if one developer builds        a module that displays an image slideshow, then that slideshow        module will work with any imported image feed. With the        conventional approach described earlier, a developer would have        to design that same slideshow module for each different image        feed that has a different schema.    -   A module developer can incorporate other modules into a custom        module, because modules are optionally completely encapsulated        to accept high-level input and to generate output. This feature        enables the type of sharing available in an open-source        environment, but unlike in an open-source environment,        developers are able to conceal source code. So if a first module        performs some but not all functions that a user wants, then        another developer can just add functionality without redesigning        the first module from scratch and without having access to the        source code of the first module.    -   The CMS optionally handles all content management, and the CMS        handles the administration UI for the modules. Modules are        therefore likely to remain compatible as new versions of the CMS        are released.    -   Users can migrate content from an old CMS to a new adaptive CMS        by exporting their old content as a feed, and then by giving the        location of that feed to the adaptive CMS. With the conventional        approach, migrating from an old CMS requires a custom plugin.    -   If a user likes the way the old CMS manages content, but prefers        the way the new adaptive CMS displays the content, then the user        can continue to manage that content via the old CMS. The user        would just set the adaptive CMS to regularly sync with a feed        from that old CMS. As described earlier, with the conventional        approach, this scenario requires custom software development.    -   Because modules are not designed to work with only one feed or        with only one schema in particular, a user can change the        contents of an entire website by first importing a new feed and        then assigning the attributes of that feed to the already        created page layouts. Users do not have to find or develop new        modules to work with the new feed.    -   In the case of the three example data feeds shown in the Program        Listing section, a user could change the import details on a        content set from referencing one feed (e.g., the JSON feed) to        referencing another feed (e.g., the CSV feed). Although both        feeds are in different markup languages and might be stored at        different locations, both feeds have the same relationship        between information. Therefore, page layouts and modules will        interact with any of the three data feeds identically, and the        previous configuration would still be accurate.

CONCLUSION

Thus, as described herein, using the example adaptive content managementsystem and process, scenarios that once required a high level oftechnical knowledge (e.g., combining several different feeds fromseveral different locations into one coherent website) now no longerrequire that a user understand even a single markup or programminglanguage. Indeed, a user with a high level of technical knowledge cansave a significant amount of time and effort by using an adaptivecontent management system (CMS).

Furthermore, certain embodiments of the adaptive CMS have additionaloptional advantages, including one or more of the following:

-   -   Because an adaptive CMS adapts to the relationship of content        stored within a data feed, optionally all content is treated        equally regardless of its data structure or format.    -   Users can pull and use data from a variety of feeds without        having to install or build custom plugins.    -   Migrating from one CMS to another is a common scenario, however        many conventional systems will support migration in only        specific instances. By creating an environment that is agnostic        to the structure of content, an adaptive CMS is able to import        content from any CMS that can export content as a data feed.    -   By not committing to one particular content structure, an        adaptive CMS lets a user manage content in multiple content        management systems and then synchronize the content in order to        output one website. For example, the user may merely need to        copy and paste a URL to the content and cause the        synchronization to be initiated; the user does not need to        develop custom software or even install custom plugins in order        to synchronize the content.    -   By not depending on content to have a particular structure, an        example adaptive CMS can completely change the content on a site        by synchronizing with a different feed and then assigning the        attributes of that feed to the already present page layouts.

Program Listing

The following section provide several non-limiting examples. The exampleXML, JSON, and CSV data feeds all contain the same information, but theyare structured using three different markup languages. These threeexamples are not meant to be all inclusive of possible types of datafeeds; for example, data feeds might be in any schema, and data feedsmight even be encoded in machine-readable formats such as Excel BinaryFile Format (XLS).

Example XML Feed

   <?xml version=“1.0” encoding=“UTF-8”?>    <teas>          <tea>          <id>3</id>           <name>Peppermint</name>          <caffeine>0</caffeine>           <type>Herbal</type>          <description>It's better than tea.           It'speppermint.</description>           <price>4.99</price><image>http://example.com/feeds/imgs/tea_bag_peppermint.png </image><thumb>http://example.com/feeds/imgs/tea_bag_peppermint_small.png</thumb>          </tea>          <tea>           <id>2</id>          <name>Ginger Mint</name>           <caffeine>0</caffeine>          <type>Herbal</type>           <description>Some days you getthe ginger mint, and some days the ginger mint gets you.</description>          <price>5.99</price><image>http://example.com/feeds/imgs/tea_bag_ginger_mint.png </image><thumb>http://example.com/feeds/imgs/tea_bag_ginger_mint_small.png</thumb>          </tea>          <tea>           <id>1</id>          <name>Earl Grey</name>           <caffeine>50</caffeine>          <type>Black</type>           <description>Earl Grey tea isflavored with bergamot to imitate more expensive types of Chinesetea.</description>           <price>3.99</price><image>http://example.com/feeds/imgs/tea_bag_earl_grey.png</image><thumb>http://example.com/feeds/imgs/tea_bag_earl_grey_small.png</thumb>          </tea>    </teas>

Example JSON Feed

         [           {           “id”: “3”,           “name”:“Peppermint”,           “caffeine”: “0”,           “type”: “Herbal”,          “description”: “It's better than tea. It's          peppermint.”,           “price”: “4.99”,           “image”:“http://example.com/feeds/imgs/           tea_bag_peppermint.png”,          “thumb”:“http://example.com/feeds/imgs/tea_bag_peppermint_small.png”          },           {           “id”: “2”,           “name”: “GingerMint”,           “caffeine”: “0”,           “type”: “Herbal”,          “description”: “Some days you get the ginger mint, and somedays the ginger mint gets you.”,           “price”: “5.99”,          “image”: “http://example.com/feeds/imgs/          tea_bag_ginger_mint.png”,           “thumb”:“http://example.com/feeds/imgs/tea_bag_ginger_mint_small.png”          },           {           “id”: “1”,           “name”: “EarlGrey”,           “caffeine”: “50”,           “type”: “Black”,          “description”: “Earl Grey tea is flavored with bergamot toimitate more expensive types of Chinese tea.”,           “price”:“3.99”,           “image”: “http://example.com/feeds/imgs/          tea_bag_earl_grey.png”,           “thumb”:“http://example.com/feeds/imgs/tea_bag_earl_grey_small.png”           }   ]

Example CSV Feed

id, name, caffeine, type, description, price, image, thumb

“3”, “Peppermint”, “0”, “Herbal”, “It's better than tea. It'speppermint.”, “4.99”,“http://example.com/feeds/imgs/tea_bag_peppermint.png”,“http://example.com/feeds/imgs/tea_bag_peppermint_small.png”

“2”, “Ginger Mint”, “0”, “Herbal”, “Some days you get the ginger mint,and some days the ginger mint gets you.”, “5.99”,“http://example.com/feeds/imgs/tea_bag_ginger_mint.png”,“http://example.com/feeds/imgs/tea_bag_ginger_mint_small.png”

“1”, “Earl Grey”, “50”, “Black”, “Earl Grey tea is flavored withbergamot to imitate more expensive types of Chinese tea.”, “3.99”,“http://example.com/feeds/imgs/tea_bag_earl_grey.png”,“http://example.com/feeds/imgs/tea_bag_earl_grey_small.png”

Example Associative Array Relationship

The following example demonstrates the relationship of data in a feedstored using an associative array, but other methods of storing the datamay also be used.

         array(3) {           [1]=>           array(8) {          [“id”]=>           string(1) “1”           [“name”]=>          string(9) “Earl Grey”           [“caffeine”]=>          string(2) “50”           [“type”]=>           string(5)“Black”           [“description”]=>           string(87) “Earl Grey teais flavored with           bergamot to imitate more expensive types ofChinese tea.”           [“price”]=>           string(4) “3.99”          [“image”]=>           string(51)“http://example.com/feeds/imgs/           tea_bag_earl_grey.png”          [“thumb”]=>           string(57)“http://example.com/feeds/imgs/tea_bag_earl_grey_small.png”           }          [2]=>           array(8) {           [“id”]=>          string(1) “2”           [“name”]=>           string(11)“Ginger Mint”           [“caffeine”]=>           string(1) “0”          [“type”]=>           string(6) “Herbal”          [“description”]=>           string(74) “Some days you get theginger mint, and some days the ginger mint gets you.”          [“price”]=>           string(4) “5.99”           [“image”]=>          string(53) “http://example.com/feeds/imgs/          tea_bag_ginger_mint.png”           [“thumb”]=>          string(59)“http://example.com/feeds/imgs/tea_bag_ginger_mint_small.png”          }           [3]=>           array(8) {           [“id”]=>          string(1) “3”           [“name”]=>           string(10)“Peppermint”           [“caffeine”]=>           string(1) “0”          [“type”]=>           string(6) “Herbal”          [“description”]=>           string(38) “It's better than tea.It's peppermint.”           [“price”]=>           string(4) “4.99”          [“image”]=>           string(52)“http://example.com/feeds/imgs/           tea_bag_peppermint.png”          [“thumb”]=>           string(58)“http://example.com/feeds/imgs/tea_bag_peppermint_small.png”           }

The methods and processes described herein may have fewer or additionalsteps or states and the steps or states may be performed in a differentorder. Not all steps or states need to be reached. The methods andprocesses described herein may be embodied in, and fully or partiallyautomated via, software code modules executed by one or more general orspecial purpose computers comprising one or more hardware computingdevices. The code modules may be stored in any type of non-transitorycomputer-readable medium or other computer storage device. Some or allof the methods may alternatively be embodied in whole or in part inspecialized computer or state machine hardware. The results of thedisclosed methods may be stored in any type of computer data repository,such as relational databases and flat file systems that use volatileand/or non-volatile memory (e.g., magnetic disk storage, opticalstorage, EEPROM and/or solid state RAM). The servers discussed hereinmay include (or be hosted on systems that include) network interfacesconfigured to receive document requests (e.g., webpage requests from abrowser) and to transmit responses to the requester. The servers andother devices described herein may optionally include displays and userinput devices (e.g., keyboards, touch screens, mice, voice recognition,gesture recognition, etc.).

Many variations and modifications may be made to the above-describedembodiments, the elements of which are to be understood as being amongother acceptable examples. All such modifications and variations areintended to be included herein within the scope of this disclosure. Theforegoing description details certain embodiments. It will beappreciated, however, that no matter how detailed the foregoing appearsin text, the invention can be practiced in many ways. The use ofparticular terminology when describing certain features or aspects ofcertain embodiments should not be taken to imply that the terminology isbeing re-defined herein to be restricted to including any specificcharacteristics of the features or aspects of the invention with whichthat terminology is associated.

All of the methods and processes described above may be embodied in, andfully automated via, software code modules executed by one or moregeneral purpose computers. The code modules may be stored in any type ofcomputer-readable medium or other computer storage device. Some or allof the methods may alternatively be embodied in specialized computerhardware. The results of the disclosed methods may be stored in any typeof computer data repository, such as relational databases and flat filesystems that use magnetic disk storage and/or solid state RAM.

While the phrase “click” may be used with respect to a user selecting acontrol or the like, other user inputs may be used, such as voicecommands, text entry, gestures, etc.

Many variations and modifications may be made to the above-describedembodiments, the elements of which are to be understood as being amongother acceptable examples. All such modifications and variations areintended to be included herein within the scope of this disclosure. Theforegoing description details certain embodiments of the invention. Itwill be appreciated, however, that no matter how detailed the foregoingappears in text, the invention can be practiced in many ways. As is alsostated above, the use of particular terminology when describing certainfeatures or aspects of the invention should not be taken to imply thatthe terminology is being re-defined herein to be restricted to includingany specific characteristics of the features or aspects of the inventionwith which that terminology is associated.

What is claimed is:
 1. A computer-implemented method of configuring aweb page layout, the method comprising: providing a user access to alibrary of modules usable to configure a layout of a webpage, wherein agiven module from the library of modules is user configurable, withoutthe user programming in a programming language, to control how contentis to be displayed on a webpage; enabling the user to drag and drop oneor more modules from the library of modules onto a webpage layout designarea to define a webpage layout; providing, for a given module selectedby the user, a module configuration user interface, wherein the moduleconfiguration user interface enables the user to specify what content isto be displayed on the webpage being designed and how the content is tobe displayed without the user having to program using a programminglanguage, wherein the module user interface comprises interfacesconfigured to receive at least: access information for content from asource, the access information including at least a content locator;content attributes comprising at least one attribute affecting howcontent from the source is displayed; receiving a user specified layoutfor a first webpage specified by the user via the webpage layout designarea, wherein the user specified layout comprises a layout of aplurality of modules, including: a first instantiation of a first moduleconfigured by the user to specify access information and at least oneattribute for a first content source that provides content using a firstcontent format; a second instantiation of the first module configured bythe user to specify access information and at least one attribute for asecond content source that provides content using a second contentformat, the second content format different than the first contentformat; accessing content from the first content source based at leastin part on the user configuration of the first instantiation of thefirst module, including at least a portion of the user specified accessinformation for the first source, wherein the content from the firstcontent source utilizes the first content format; storing content fromthe first content source in a schema-less data store; accessing contentfrom the second content source based at least in part on the userconfiguration of the second instantiation of the first module, includingat least a portion of the user specified access information for thesecond source, wherein the content from the second content sourceutilizes the second content format; storing content from the secondcontent source in the schema-less data store; and enabling the webpageto be rendered, including the content from the first content source andthe content from the second content source.